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FIELD OF THE INVENTION 



This invention relates to the field of computer technology. More 
specifically, the invention relates to a method and system for performing 
collective validation of credential information (e.g., license and /or appointment 
data). 

Portions of the disclosure of this patent document contain material that is 
subject to copyright protection. The copyright owner has no objection to the 
facsimile reproduction by anyone of the patent document or the patent 
disclosure as it appears in the Patent and Trademark Office file or records, but 
otherwise reserves all copyrights whatsoever. 

BACKGROUND 

There are many complexities to the financial services business. At any 
given time large amounts of sales transaction data must be organized and 
processed. Such data may relate to many types of sales transactions and much of 
it is necessary to keep the business running smoothly. Some of the more 
significant classifications of sales transaction data stem from the fact that in the 
financial services business there are multiple distribution channels each with 
multiple distributors and many different incentive plans for employees. In most 
instances, these incentive plans are constantly modified and changed. This is 
particularly true in the financial services sector where distributors and sales 
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representatives may require certain licenses and appointments in order to legally 
sell certain financial instruments. The status of the license or appointment data 
changes continuously and must therefore be updated on a regular basis. 
Furthermore, the volume of sales transactions is large, and for each transaction a 
number of tests must carried out to validate the sales agents' credentials and 
compute the compensation amounts associated with the sales transactions. 

Updating such a large amount of records is a cumbersome process that 
can require significant system resources. Thus, systems must be configured to 
efficiently validate sales transactions in view of the licenses and/ or 
appointments necessary to legally complete the transaction. Existing systems do 
not currently have a mechanism for processing such data in a way that 
minimizes the time required to process license and appointment data and 
validate a sales agent's credentials before distributing compensation to the sales 
agent for the transaction. Therefore there is a need for an improved mechanism 
for processing sales transaction data. 
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SUMMARY OF THE INVENTION 



An embodiment of the invention comprises a method and apparatus for 
performing collective validation of credential information. The invention has 
applicability in industries that require sales agents or those related to the 
distribution of a certain product to be credentialed (e.g., licensed and /or 
appointed) when selling certain products (e.g., life insurance, etc.). For 
example, in order to sell some financial instruments sales representatives must 
meet state and/or federal licensing requirements. Embodiments of the invention 
provide a way to ensure that sales representatives operate within any regulatory 
constraints put in place by government or any other organization. Companies 
may, for instance, utilize embodiments of the invention to ensure that sales 
representatives operate within a set of defined constraints. 

One aspect of the invention provides a method for validating sales agents' 
credentials while processing the sales transaction data to determine commission 
amounts. The system is configured to perform such transaction processing in an 
efficient manner that minimizes the amount of computational resources required 
to determine whether a sales agent has valid credential at the time of a particular 
sale and is therefore entitled to compensation (e.g., a commission) for the sale. 
The system may process one or more transactions at a time and may perform 
transaction processing collectively if such processing is desirable. 
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In an embodiment of the invention, the compensation engine or some 
other software component determines the grouping of input such that validation 
can be performed collectively (e.g., in batch). For instance, the compensation 
engine may perform an initialization process where it obtains credential 
5 information that relates to the sales agents and assembles the credential 
information into a denormalized table. The system may obtain credential 
information (e.g., licensing and /or appointment data) from several tables of a 
database and put the credential information into a single denormalized table. 
The system may also load rule information that can be utilized to process the 

O 

%Q 10 credential information. This rule information may be provided to the system in 

ffi 

y3 any structured form (e.g., text, XML, etc. ..) and the rule data may comprise a set 

0"! 

£a of tests for determining if a particular transaction was valid. In one embodiment 

J of the invention, the system instantiates an instance of an object oriented class 

referred to as the RuleSet class. The RuleSet class and a set of associated object 
15 reachable from that class (e.g.,. preconditions, test, etc. . .) provide the 

functionality referred to as the rule engine. Thus, the rule engine may comprise 
a collection of objects working together. However, the invention also 
contemplates other software or hardware mechanisms configured to provide rule 
engine functionality. The objected oriented examples provided herein are for 
20 illustrative purposes and the reader should note that other non-objected oriented 
programs may be configured to provide the functionality described herein. 

Once the rule information is loaded, an embodiment of the invention 
utilizes the rule information to determine if the distributor (e.g., sales agent) 
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specified in the transaction was properly credited. Thus, the system obtains a set 
of transactions (e.g., a batch) associated with one or more sales agents and 
utilizes the transaction data to determine if a commission amount associated 
with each transaction may be credited to one or more of the sales agent's 
accounts. Compensation is distributed when the constraints placed on the sales 
transaction are satisfied. For example, a sales representative that made a sale 
under an invalid credential (e.g., a license or appointment) will not be 
compensated for the sales. Thus, part of the compensation process involves 
determining the validity of the sales agent's credentials (e.g., license and/or 
appointment data). 

In one embodiment of the invention, the process associated with 
determining whether the credential data is valid involves converting each 
transaction to input usable by the rule engine. A collective set of rule engine 
input may then be provided to the system to perform validation. The process of 
determining whether the transaction input is valid may involve determining the 
set of rules that apply to the input by filtering the rules using a set of 
preconditions. The set of tests may then be partitioned by test type and each test 
type is associated with the transaction input. Once the association occurs a 
candidate for each test type is selected and a collective group of the tests of a 
particular type is formulated. The group of tests is then input to the system for 
processing. The reader should note, however, that the invention does not require 
that such test data be input collectively (e.g., in batch). The test data (e.g., tests of 
a particular type) may also be input individually or in any other categorical 
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methodology that provides the test data to the system. The results can be stored 
in cache for later use by the system. 

For each rule associated with each input, the system determines if the test 
conditions are met. If the test conditions are met, the transaction data with 
respect to that test type is considered valid. The system may use the cached 
results to determine if the test conditions are met. The results indicate which of 
the transactions are valid and can therefore be utilized to determine which sales 
agents to compensation for a particular transaction. 

In an embodiment of the invention, the functionality is accomplished 
through the use of a set of software and/ or hardware components configured to 
determine whether a sales transaction should result in a credit to the sales agent 
associated with the transaction. The system may perform this by utilizing a 
compensation engine configured to communicate with the rule engine. In one 
embodiment of the invention, the rule engine comprises a collection of software 
interrelated components. 
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DESCRIPTION OF THE DRAWINGS 



Figure 1 shows a flowchart of the steps in an example that illustrates the 
validity checks of credentials according to an embodiment of the invention. 

Figure 2 shows a class diagram and relationships representing object 
models for licenses (e.g., credentials) in an embodiment of the invention. 

Figure 3 shows a block diagram illustrating data communication during 
credential validation process in an embodiment of the invention. 

Figure 4 shows a flowchart illustrating the steps involved in validating 
distributors credentials in an embodiment of the invention. 

Figure 5 shows a flowchart illustrating the steps involved in validating 
credential using an alternative approach to credential validation in an 
embodiment of the invention. 
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DETAILED DESCRIPTION 



The invention provides a method and apparatus for performing collective 
validation of credential information. In the following description, numerous 
specific details are set forth in order to provide a more thorough understanding 
of the invention. It will be apparent, however, to one skilled in the art, that the 
invention may be practiced without these specific details. In other instances, 
well-known features have not been described in detail in order to avoid 
unnecessarily obscuring the invention. 

System Overview: 

An embodiment of the invention comprises a method and apparatus for 
performing collective validation of credential information (e.g., license and/ or 
appointment data or any other set of constraints upon a sales transaction). More 
specifically, the invention provides a method for validating sales agents' 
credentials while processing sales transaction data to determine commissions to 
be paid. The system is configured to perform such transaction processing in a 
manner that decreases the amount of time and resources required to determine 
whether a sales agent has a valid credential at the time of a particular sale and is 
therefore entitled to compensation (e.g., a commission) for the sale. The system 
may process one or more transactions at a time and may perform transaction 
processing collectively if such processing is desirable. The specifics of the 
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improved system for processing such transaction data will be described in 
further detail below. 

The invention may be integrated into an extensible system for managing 
relationships between institutions (e.g., suppliers /manufacturers) of a product or 
service and the distributors (e.g., sales representatives) of their product. Systems 
embodying the invention have applicability in industries that require sales 
agents or those related to the distribution of a certain product or service to be 
credentialed (e.g., licensed or appointed) in order to sell the product. For 
example, in order to sell a certain financial instrument a sales representative 
might be required to have a state and /or federal license to sell that type of 
financial instrument. 

Companies or organizations may utilize the invention to enforce 
agreements the company has with distributors who sell their products. Thus, the 
system may enforce an agreement stating that all sales transactions are to be 
performed by sales representatives or distributors who have valid credentials. 
This provides organizations such as life insurances companies a way to manage 
the sale and distribution of life insurance plans in a way that coincides with the 
regulatory constraints of government organizations. Whether a particular 
distributor or sales representative is appropriately credentialed can be viewed as 
a regulatory constraint. The system ensures that such regulatory constraints are 
not violated when a transaction is executed. Although, licenses and/ or 
appointments are utilized as examples of the types of credentials that may be 
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validated by embodiments of the invention, the term credentials as it utilized 
encompasses any set of constraints or requirements associated with a sales 
transaction. For instance, company policies or individual constraints that vary 
on a product by product basis, or any other set of definable constraints can also 
5 be enforced by the system by implementing such items as "credentials" that may 
be required for a sales representative to be compensated. Transactions that do 
not conform to the government regulations are not typically executed and may 
not therefore result in any compensation to the sales representative(s) or 
^ distributor(s) associated with the transaction. In accordance with one 

® 10 embodiment of the invention, credential checks are collectively submitted to the 

03 

system for processing. This decreases the time and resources required to process 
H the credential information. 

r** 

B 

□ The invention may use multiple techniques for processing the sales 

m 

Pj transaction data in order to determine whether a sales agent has valid credential 

q 15 at the time of a particular sale and is therefore entitled to compensation (e.g., a 
commission) for the sale. In an embodiment of the invention, a compensation 
engine or some other software component determines an arrangement of input 
such that validation can be performed collectively (e.g., in batch). For example, 
the compensation engine may perform an initialization process where it obtains 
20 credential information that relates to the sales agents and assemble the credential 
information into a denormalized table. For instance, the system may obtain 
credential information (e.g., licensing and/or appointment information) from 
several database tables and put the credential information into a single 
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denormalized table. The initialization engine may also load rule information that 
can be utilized to process the credential information. This rule information may 
be provided to the system in any structured form (e.g., text, XML, etc..) and the 
rule data may comprise a set of tests for determining if a particular transaction 
was valid. 

In one embodiment of the invention, the system instantiates an instance of 
an object oriented class referred to as the RuleSet class. The RuleSet class and a 
set of associated object reachable from that class (e.g.,. preconditions, test, etc..) 
provide the functionality referred to as the rule engine. Thus, the rule engine 
may comprise a collection of objects working together. For instance, the system 
may interact with a RuleSet instance through a rule container class or some other 
type of interface (e.g., a license and appointment class). Upon initialization, a 
RuleSetlmporter may be utilized to obtain the rule information (e.g., XML files 
that define the rules) and create an in memory representation of the imported 
rules. That representation may comprise a chain of RuleSet objects and their 
associated preconditions and tests. The reader should note that the specific 
classes and objects referred to herein are for illustrative purposes. Other non- 
objected oriented programs may be configured to provide the same functionality. 

Once the rule information is loaded (e.g., via the RuleSetlmporter or some 
other mechanism), an embodiment of the invention utilizes the rule information 
to determine if the distributor (e.g., sales agent) specified in the transaction was 
properly credited. Thus, the system obtains a set of transactions (e.g., a batch) 
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associated with one or more sales parties and utilizes the transaction data to 
determine if a commission amount associated with each transaction should be 
credited. Compensation is distributed when the constraints placed on the sales 
transaction are satisfied. For example, a sales representative that made a sale 
under an invalid credential (e.g., license or policy) will not be compensated for 
the sales. Thus, part of the compensation process involves determining the 
validity of the sales agent's credentials (e.g., license and/ or appointment data). 

In one embodiment of the invention, the process associated with 
determining whether the credential data is valid involves converting each 
transaction to input usable by the rule engine. A collective set of rule engine 
input may then be provided to the system to perform validation. In one 
embodiment of the invention, the process of determining whether the transaction 
input is valid involves determining the set of rules that apply to the input by 
filtering the rules using a set of preconditions. 

The set of tests may then be partitioned by test type and each test type is 
associated with the transaction input. Once the association occurs a candidate 
for each test type is selected and a collective group of all tests of a particular type 
is formulated for input. The tests are then provided to the system for processing. 
The results can be stored in cache for later use by the system. For each rule 
associated with each input, the system determines if the test conditions are met. 
If the test conditions are met, the transaction data with respect to that test type is 
considered valid. The system may use the cached results to determine if the test 
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conditions are met. The results indicate which of the transactions are valid and 
can therefore be utilized to determine which sales agents to compensation for a 
particular transaction. 

The methodology for collectively submitting credential checks to the 
system for processing in accordance with one embodiment of the invention is 
described in further detail below (see e.g., Section entitled License and 
Appointments Validation). 

Introduction to Licenses and Appointments 

So that the reader gains an understanding of the type of credential 
information that may be validated by embodiments of the invention, a brief 
description of credentials such as licenses and /or appointments follows. 
Licenses within an embodiment of the invention may equate to physical licenses 
issued by jurisdictions (e.g., federal, state/province). To receive compensation 
for a sale, the system ensures that distributors are appropriately licensed and that 
each individual who receives compensation is appointed to make such sales (e.g., 
an agent). 

The system may also determine whether parties associated with the 
transaction (e.g., distributors and/or sales representatives) have an up to date 
and valid credential (e.g., license). For example, the system may keep track of 
continuing education credits to determine how many courses a distributor has 
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taken. The system may use the continuing education credits to determine if a 
distributor meets credential (e.g., appointment and/or license) requirements. An 
institution is typically required when defining appointment types. Like 
individuals, institutions may be represented in the system as parties, agents, 
sales representatives or distributors. The system may also require a regulatory 
jurisdiction when defining certain credential types. An embodiment of the 
invention comprises a mechanism for specifying credential information and 
defining the rules that govern credentials (e.g., licenses) held by parties. Figure 1 
provides an example of some of the decisions that may be made when checking 
the validity of credentials such as licenses or appointments. For example, the 
user may specify rules that define one or more of the following types of 
credential (e.g., license) information: 

1. The educational credits required in order to hold a specific type of 
credential (e.g., step 102). For example, License L requires X units of 
education credit C. 

2. The renewal requirements for a specific type of credential (e.g., step 104). 
For example, License L must be renewed every T units of time. 

3. The residency rules associated with a specific type of credential (e.g., step 
106). For example, License L is required in jurisdiction J. The user may 
associate credential types with product types and a jurisdiction through 
credential entries in a distributor's credential record. The record may 
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include <credential type, product, and jurisdictions Access to the 
credential rules through the distributor credential record enables the user 
to define information relating to the following questions, while factoring 
in such elements as the type of product to be sold or the state in which it 
will be sold: 

a. Is a distributor qualified to hold a credential (for instance, does the 
distributor have sufficient educational credits)? 

b. Does the distributor have the right credential to sell (e.g., step 100), 
Credentials, Jurisdiction, Education Credits, Products service, or 
illustrate a product? 

Does the distributor have a credential that will expire (e.g., step 108) within a 
specified period of time? If any of the above conditions indicates the transaction 
is not valid, the system executes step 110 where it may stop execution of the 
transaction relating to the invalid credential. Thus, the sales representative may 
not receive any compensation for invalid transactions. The system's credentialing 
mechanism may be utilized to define credential parameters relating to any party 
in the system (e.g., institutions, distributors, sales representatives, agents, etc.). 

An embodiment of the invention also provides a mechanism for 
identifying and defining the rules that govern appointments held by parties. For 
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example, the user may specify rules that define one or more of the following 
types of information: 

1. Does a specific appointment require a certain license (e.g., step 112)? For 
example, Appointment A requires license L. 

2. Does an appointment require errors and omissions (E & O) coverage (e.g., 
step 114)? For example, Appointment A requires E&O coverage by 
Distributor D. 

3. What are the renewal requirements for a specific type of appointment 
(e.g., step 116)? For example, Appointment A must be renewed every T 
units of time. 

4. What are the residency rules associated with a specific type of 
appointment (e.g., step 118)? For example, Appointment A is required in 
jurisdiction J. The association of an appointment type with a product type, 
a jurisdiction, and an institution is made in the appointment record 
associated with a distributor. The record specifies <appointment type, 
product, jurisdiction, and institution . The user can access the 
appointment rules through the distributor license record. These rules 
enable the user to determine outcomes associated with the following 
questions, while factoring in such elements as the type of product to be 
sold or the state in which the product will be sold: 
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a. Is a distributor qualified to hold an appointment? For example, do 
does the distributor have sufficient E&O coverage? 

b. Does the distributor have the right appointment to sell a product? 

c. Does the distributor have an appointment that will expire within a 
specified period (e.g., step 120)? 

d. What are the cancellation rules associated with an appointment? 
The set of appointment rules of the system software can be 
Appointments, Licenses, Products, Jurisdiction 

If any of the above conditions indicate the appointment if not valid, the system 
may execute step 126 where it stops execution of the transaction relating to the 
invalid appointment. If the conditions are met, the system executes step 122, 
where it flags the transaction being processed as valid and passes the transaction 
data to commission engine for processing. 

Transaction Processing Overview 

Once the credential information (e.g., licensing and appointment data) is 
defined. The system may be configured to process transaction data associated 
with the sale of different products. The system may be configured to ensure that 
the terms of a selling agreement (e.g., an agreement between the parties 
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involved) are followed and that the credential (e.g., licensing and/ or 
appointment or other agreed upon constraints) requirements are not violated 
with respect to each transaction executed by the system. Sales transaction data 
comprises the information associated with the sale of one or more products. The 
system is configured to process one or more transactions at a time and may 
perform transaction processing collectively (e.g., in batch) if such processing is 
desirable. However, the invention also contemplates other forms of transaction 
processing and may, for example, process each transaction entered into the 
system when it is entered. 

In an embodiment of the invention, the system converts the transaction 
data into a form that can be processed by the system. For example, the 
transaction data may be loaded into an object model configured to interface with 
the system embodying one or more aspects of the invention. The transaction 
data may indicate which party sold what to whom and identify the appropriate 
agreements associated with the sale. For example in accordance with one 
embodiment of the invention, the transaction data identifies which distributor 
was responsible for the sale and what agreement that distributor is operating 
under. The system resolves the associations contained in the transaction data 
and thereby determines the scope of analysis to be performed. 

In an embodiment of the invention, the system also checks on credentials 
(e.g., licenses and/or appointments) for the distributor's supervisors. The 
system may require a license validation when appointments are processed. The 
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• 



logic associated with such processing in accordance with one embodiment of the 
invention performs the following steps: 

1. Determines the credential (e.g., license and/or appointment) requirements 
for the distributor based on the values of the product, jurisdiction, and 
institution parameters passed to the function. 

2. Determines whether the distributor possesses the required credential (e.g., 
license and /or appointment) types, or a blanket assignment. For example, 
some states do not permit a corporation to be licensed, but instead require 
them to have a blanket assignment. The rules evaluation used to 
determine the required license and/ or appointments can also include 
other factors such as the compensation type (for example, the first year 
commission or renewal), the residency of the distributor, or the role of the 
distributor. 

If the credential requirements are met, the system may perform commission 
processing. Otherwise an error results and the transaction associated with the 
error is not processed by the system. 

In an embodiment of the invention, the system also identifies any other 
agreement objects affected by the input transaction. If the system locates an 
affected agreement object, it creates additional transactions that process 
compensation according to the newly identified agreement commission models. 
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Once all input transactions have been associated with agreements, the system 
may invoke the commission engine and performs commission processing. 
However, the system may also enforce credentials and/ or constraints 
independent of any agreement. For instance, companies may use the system to 
enforce an internal set of credential requirements, policies and/or constraints. 

Commission processing involves determining the amounts to be paid to 
parties involved in the sales transaction. In one embodiment of the invention 
this occurs by processing the transaction based on rules defined by the selling 
agreement. However, the rules utilized by the system are not required to be 
defined in selling agreements. For example, the system may use rules defined in 
a manner independent of any selling agreement. 

Distributor Data object model 

Figure 2 shows a class diagram and relationships representing object 
models for credentials (e.g., licenses) in an embodiment of the invention. The 
specific objects described herein are provided for illustrative purposes only and 
the reader should note that the invention also contemplates other software or 
hardware configurations that provide the functionality described herein. A 
distributor data object model 230 defines the data that is associated with a 
distributor and that is utilized to manage the Licensing and Appointments 
package. The distributor data object model has several properties comprising a 
Selflnsured property that may indicate if the distributor is self-insured. If not, 
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then there may be associated FSEOPolicy objects. For example, the system may 
include a set of components (e.g., methods) configured to implement the 
following general functionality: 



• RecontractStatus may indicate whether or not an inactive 
distributor may enter into another contract (Valid only if IsActive() 
returns false); 

• RecontractReason may indicate why the distributor may not be re- 
contracted (if applicable, Valid recontract reason codes can be 
defined in XML or any other structured data format); 

• IsActive() which may indicate if the distributor is active, that it, has 
appointments still in effect; 

• IsAppointed() which may indicate if the distributor is properly 
credentialed (e.g., licensed and/or appointed) to receive credit for a 
transaction (Ensures that there is a valid credential such as an 
appointment and /or associated license for the date of the 
transaction). In one embodiment of the invention, the IsAppointed 
method evaluates whether a given party in a specific jurisdiction is 
legally capable of selling a specific product; 
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• IsLicensed() which may indicate if the distributor is properly 
licensed (ensures that there is a valid credential (e.g., license) for 
the date of the transaction. The IsLicensed method evaluates 
whether a given party in a specific jurisdiction is legally permitted 
to sell a specific product; 

• IsBonded() which may indicate if the distributor is bonded (i.e., has 
an EOPolicy of type Bond Info); 

• HasGeneralLiability() which may indicates if the distributor has 
general liability insurance (i.e v has an EOPolicy of type General 
Liability Insurance); 

• getLicenses() which may return a collection of all FSLicense objects 
associated with the distributor; 

• getAppointments() which may return a collection of 
FSAppointment objects associated with the distributor; 

• getAUEOCoverages() which may return a collection of FSEOPolicy 
objects associated with the distributor; 

• getBackgroundChecks() which may denote a collection of 
FSBackgroundCheck objects associated with the distributor; 
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• getCECredits() which may denote a collection of 
FSContinuingEducationCredit objects associated with the 
distributor; 

• getEOPolicies() which may return a collection of all FSEOPolicy 
objects of type Errors and Omissions Policy associated with the 
distributor; 

• getBondInfo() which may return a collection of all FSEOPolicy 
objects of type Bond Info associated with the distributor; 

• getGeneralLiability() which may return a collection of all 
FSEOPolicy objects of type General Liability Insurance associated 
with the distributor. 

The names utilized to describe components, objects, and /or methods 
referred to above and throughout this description are for example only. The 
invention contemplates any component or set of components that implements 
the functionality described therein. 

Licensing Object Models 

In an embodiment of the invention, the system comprises a License class 
which represents a physical license issued to a distributor. The license class has 
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several properties comprising a LicenseType denoting the type of license (for 
example, agent, broker, and so on). The license types may be defined in a 
structured file such as an XML file. The system may include the following 
components: 



• a LicenseClass denoting the class of license (for example, 
individual, corporate, partnership and may define the license 
classes in a structured file; 



• a LicenseNumber denoting the license number. This can be any 
alphanumeric string; 

• Jurisdiction denotes the jurisdiction (state/province) associated 
with the license. Jurisdiction codes are defined in a structured file 
such as XML; 



• The ResidentStatus may indicate whether the party associated with 
the appointment is a resident of the jurisdiction for which it is 
valid. The class may also include a LegalName denoting the legal 
name of the distributor as it appears on the license; 

• a DBAName denoting the "Doing Business As" name as it appears 
on the license; 



85160.922/T00068 



25 



Express Mail #EL551405989US 



• a DistributorData denoting a backpointer to the FSDistributor Data; 

• a Terminate() to mark the license as being terminated; 

• a Renew() to renew the license for the specified period; 

• a getLicenseLines() providing a helper function that returns a 
collection of FSRequests associated with this FSLicense; 

• a getRequests() providing a helper function that returns a collection 
of FSRequests associated with this FSLicense;LicenseLine 210 class 
may represent the line of insurance covered by particular license. 
Licenseline 210 class has several properties comprising a 
LicenseLine denoting the line of authority for the license; 

• a License denoting the associated FSLicenseDocumentation; 

• a Terminate to mark the license line as being terminated; 

• a Renew to renew the license line for the specified period; 

• one or more LicenseLine classes may be instantiated by a License 
class 220. 
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a License 220 class may represent a physical license issued to a 
distributor. The license class 220 can have several methods and 
properties comprising: 

• a LicenseType , a LicenseClass, a LicenseNumber, a Jurisdiction, 
ResidentStatus and a LegalName. LicenseType may designate the 
type of license (for example, agent, broker, and so on). 

• LicenseClass designates the class of license (for example, 
individual, corporate, partnership). 

• LicenseNumber designates the license number. Jurisdiction 
designates the jurisdiction (state /province) associated with the 
license (Jurisdiction codes may be defined in an XML format). 

• ResidentStatus indicates whether the party associated with the 
appointment is a resident of the jurisdiction for which it is valid. 

• LegalName designates the legal name of the distributor as it 
appears on the license. A helper function that returns a collection of 
requests associated with this License 220. In an embodiment of the 
invention, one or more instances of the License 220 class may be 
associated with a status class 1050 and an appointment class 240. 
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Appointment Object Model 



In an embodiment of the invention, an appointment class 240 encapsulates 
the data associated with an appointment (e.g., a type of credential). The 
appointment object model may comprises the following: 

• a License denoting the License associated with this appointment; 

• a Jurisdiction denoting the jurisdiction (state/ province) associated 
with the appointment (The jurisdiction is determined by the 
licenses associated with the appointment. It is provided on the 
appointment for convenience. Jurisdiction codes can be defined in 
XML format or some other format.); 



• a Subjurisdiction denoting the sub-jurisdiction (county) associated 
with the appointment (This field is only applicable for certain 
jurisdictions. Sub-jurisdiction codes are defined in an XML format); 

• a Company denoting the financial services company for which the 
appointment is being issued; 

• a ResidentStatus indicating whether the party associated with the 
appointment is a resident of the jurisdiction for which it is valid; a 
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Parent indicating the distributor firm from which the blanket 
appointment comes; 

• a Distributor Data denoting a backpointer to the FSDistributorData. 

License and Appointments Validation 

Figure 3 shows a block diagram illustrating data communication during 
the credential (e.g., license) validation process in accordance with an 
embodiment of the invention. When one or more transaction inputs 340 are 
received, the rule engine 320 queries the database to retrieve data related to the 
sales party involved in the transaction. The rule engine may load test rule 330 
files. Test rule files are designed by users to specify tests to be carried out on the 
transaction data. Test rules can be stored in files using a standardized format 
(e.g. XML files, text, or any other type of structured data file). The rule engine 
also loads the distributors' credential information such as the license and/or 
appointment data 350. Once the rule engine validates the credential information 
associated with the transaction against the test rules, it may store the results in 
one or more validation results files 360. The transaction data may then be 
updated with the validated credential information and returned to update the 
database. 

In an embodiment of the invention, the system is configured to process 
one or more transactions at a time and may perform transaction processing 
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collectively if such processing is desirable. The system configured in accordance 
with an embodiment of the invention may be composed of several entities 
allowing for performing one or more steps of the transaction data processing. 
An entity such as the commission engine may determine the arrangement of 
input such that validation can be performed more efficiently (e.g., collectively). 
The commission engine or some other component may ready the data for 
processing during an initialization process. The system may implement a rule 
engine, capable of determining the set of tests that need be validated. For 
example, the RuleSet class and a set of associated objects reachable from that 
class (e.g.,. preconditions, test, etc.) may provide the functionality referred to as 
the rule engine. Thus, the rule engine may comprise a collection of objects 
working together. 

The rule engine is capable of arranging the input to be passed along to an 
associated test part (e.g., iTestPart) and the compensation engine (e.g., part of the 
DMS system) runs an initialization step where data can be denormalized. The 
system can then pass off the data to a representative instance of an object 
containing the set of tests (e.g., iTtestPart). The tests may comprise an interface 
that supports the ability to perform batch validation for all other instances of 
tests given that they contain input data. In one embodiment of the invention, the 
ruleset comprises a list of rules for testing input to determine if data satisfies the 
requirements. The rules evaluate distributor's data (information about 
distributors, products, and so on) determining if it meets requirements (or 
preconditions) for the system rules. For example, the APPOINTMENT_TEST in 
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the Appointment Rule may evaluate whether a particular distributor has the 
appointments necessary to sell a product in a particular jurisdiction. The rule 
engine can determine whether compensation should be paid and whether or not 
a particular distributor is eligible to sell a particular product. 

The system may contain a set of defined rule sets. If the data satisfies the 
requirements, the rule is set considered. Each rule is made of one or more 
elements including: 

■ A precondition — Defines circumstances under which the rule applies. 
If the precondition is not satisfied, the rule does not apply. 

■ A test — A Boolean expression that determines if the rule is satisfied. 

■ An explanation — An optional message that explains the rule failure. 

In an embodiment of the invention, preconditions to a rule comprise a list of 
either generic preconditions or specialized preconditions (for example, a rule 
may apply to a particular product or jurisdiction) designed to cover common 
cases. A product precondition may be satisfied if the input refers to a given 
product specified in the precondition. This precondition can map to an object 
(SCCMProduct.Name) . 
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A product class precondition may be satisfied if the input refers to a 
product that has the class specified in the precondition. This precondition maps 
to SCCMProduct.ProductClass. In an embodiment of the invention, a 
jurisdiction set precondition is satisfied if the input refers to one of a set of 
jurisdictions specified in the precondition. 

A jurisdiction precondition may be satisfied if the input refers to a 
jurisdiction specified in the precondition. A start date precondition may be 
satisfied if the date of the input is later than or equal to the date specified. 

An end date precondition is satisfied if the date of the input is earlier than 
the date specified. 

A generic precondition is useful when more specific preconditions are 
inadequate. It is satisfied if the specified property on the specified input object 
has the specified value. 

In an embodiment of the invention, all transactions are required to pass 
however other requirements may be set. Tests can be further combined using 
standard Boolean operators AND, OR, and NOT. 

The license line test may be satisfied if the distributor referred to by the 
input has the specified license line in the specified jurisdiction. For example: 
does John Smith have a Series 66 license for California? 
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ru 



The appointment test may be satisfied if the distributor referred to by the 
input has the specified appointment in the specified jurisdiction. For example: is 
John appointed for Variable Life in New York? 

The background check test may be satisfied if the distributor referred to 
5 by the input has passed the specified background check with the specified 
decision. 

The errors and omissions test may be satisfied if the distributor referred to 
by the input has the specified level of errors and omissions coverage. 

The liability test may be satisfied if the distributor referred to by the input 
10 has the specified level of liability coverage. 

The continuing education test may be satisfied if the distributor referred 
to by the input has the specified number of continuing education credit hours. 

A generic test is useful when more specific tests are inadequate. It is 
satisfied if the specified property on the specified input object has the specified 
15 value. 

Figure 4 shows a flowchart illustrating the steps involved in validating 
credential data in accordance with an embodiment of the invention. Transaction 
data is received by the system in 410. Step 410 involves access to the system 
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automatically or manually by users through one or more means for interfacing 
the system with users (e.g. Web interface, API) described above. The system can 
determine in 420 the set of distributors associated with the transaction. The 
system then determines a set of tests to be performed for each transaction or 
5 allocation in 430. The system executes the set of tests in batch in 435. The system 
tests whether each distributor is properly licensed for of the transactions 
processed in 440. If the distributor's credentials satisfy the tests, the distributor's 
data is appointed for the transaction in 460 (e.g., the distributor is compensated). 
If a distributor's license does not satisfy the test rules in 440 then the distributor 

y3 10 is dismissed from the current transaction in 450 (e.g., no compensation is 

03 

yfl credited), and the next distributor on the list of distributors involved in the 

U transaction is selected for further license and appointments testing. Upon 

jg completion of the evaluation, the process may iterate back to step 410 or 440. 



Sj In an embodiment of the invention, a distributor may be considered as 

g 15 appropriately credentialed for a transaction if for example, on a given date, the 

i==R distributor has a credentials (e.g., a license) that is valid for the jurisdiction in 

which the transaction occurred. The code below (in Object Query Language, 

OQL) performs an example of a license check against the data as stored in the 

database, according to the object model described above: 

20 SELECT 11 

FROMFSLicenseLine 11, 
FSLicense lie, 
FSStatus licStatus, 
FSStatus UStatus 
25 WHERE ll.LicenseLine = [License Line] 
ANDU.License = lie 
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ANDlic.DistributorData = [Distributor GID] 



AND 


lic.Jurisdiction 




[Jurisdiction] 


AND 


licStatus.Object 




lie 


AND 


UStatus.Object 




11 


5 AND 


(licStatus.StartDate 


<= 


[Transaction Date] 


AND 


licStatus.EndDate 


> 


[Transaction Date] 


AND 


(llStatus.StartDate 


<= 


[Transaction Date] 


AND 


UStarus.EndDate 


> 


[Transaction Date] 


AND 


lic.StatusCode 


NOT IN (<List of Invalid Statuses>) 


10 AND 


lLStatusCode 


NOT IN (<List of Invalid Statuses>) 



A non-empty result set indicates that the distributor is properly licensed. As the 
above OQL indicates, a join is required across four (4) logical tables. This 
method however is costly in terms of processing time. Since the query performs 
y3 joins on several tables, utilizing database table indexing functionality may 

15 increase the speed. With this method the cost of determining if a distributor is 
tl licensed can be significant, especially given the number of rows that will be in 

% the tables, and especially the table associated with FSStatus. 



5 1 Distributor credential validation may be performed in steps wherein each 

^ step yields only a subset of data to be processed resulting in a faster search and 

y 

K 20 thus faster processing. 



Figure 5 comprises a flowchart illustrating the steps involved in validating 
credentials such as licenses using an alternative approach to credential validation 
in an embodiment of the invention. Data processing starts with the 
denormalization of the data from several tables to be input into a denormalized 
25 table in 510. The system obtains a distributor's credential information in 520. The 
system obtains the transaction information in 530. The system obtains test rules 
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information in 540 and then checks for credential (e.g., license) validity based on 
distributor's information, transaction information and credential information in 
550. The system then joins the results of the validation of distributor's licenses 
with the denormalized data. 



A sample Object Query Language (OQL) code performing this check 
against the data as stored according to the object model described above is as 
follows: 

SELECT app.Parent 
FROM FSLicenseLine 11, 

FSLicense lie, 

FSAppointment app, 

FSStatus appStatus, 

FSStatus licStatus, 

FSStatus UStatus 



WHERE 


ll.LicenseLine = 


[License Line] 


AND 


U.License = lie 




AND 


app.License = lie 




AND 


app.LicenseLines = 


11 


AND 


app.DistributorData 


[Distributor GID] 


AND 


app.Jurisdiction = 


[Jurisdiction] 


AND 


( app.SubJurisdiction 


= [Sub-Jurisdiction] 




OR app.SubJurisdiction 


-1 ) 


AND 


appStatus.Object = 


app 


AND 


licStatus.Object = 


lie 


AND 


llStatus.Object 


11 


AND 


(appStatus.StartDate 


<= [Transaction Date] 


AND 


appStatus.EndDate > 


[Transaction Date] 


AND 


(licStatus.StartDate <= 


[Transaction Date] 


AND 


licStatus.EndDate > 


[Transaction Date] 


AND 


(UStatus.StartDate <= 


[Transaction Date] 


AND 


UStatus.EndDate > 


[Transaction Date] 


AND 


app.StarusCode NOT IN (<List of Invalid Statuses>) 


AND 


lic.StatusCode NOT IN (<List of Invalid Statuses>) 


AND 


ll.StatusCode NOT IN (<List of Invalid Statuses>) 
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A non-empty result set indicates that the distributor is appointed. 



The system may perform credential checks when running a compensation 
engine. The reader should note, however, that such credential checks may be 
performed at other times and by other engines or components. The process of 
5 validating distributors' credentials can be referred to in an embodiment of the 
invention as the the license check phase. The compensation engine may be run 
on a periodic basis to calculate compensation for new sales transactions since the 
most recent run of the engine. A transaction will result in multiple allocations. If 

% any of these allocations are associated with the sale of any products that require 

ffl 

" 10 the distributor be credential (e.g., licensed or appointed) then the allocation 



IE 

O 
gi 

I IT 



passes through the license check phase. The number of transactions and 
allocations that are processed in any given rim varies per deployment, ranging 
from tens of thousands to several million. Thus the performance of the 
credential check phase may affect performance of the entire system. 



o 

\± 15 An embodiment of the invention ensures that credential validation can be 

efficiently performed. First, the system denormalizes the credential information 
(e.g., license and appointment data) into separate tables. To determine if a 
distributor is appropriately credentialed, the system may perform a query 
against a single table. In one embodiment of the invention, a single SELECT 
20 statement (with the exception of blanket appointments, which result in as many 
queries as the depth of the blanket appointment) can be utilized to query the 
database. The invention also contemplates other queries. To further ensure the 

37 

85160.922/T00068 Express Mail #EL551405989US 



performance of the credential check phase, the system is enabled to collectively 
perform license and appointment checks (also referred to herein as credential 
checks). In an embodiment of the invention, the size of the collection of data to 
be submitted (e.g., a batch) is determined by the commission engine's batch size. 
5 In an embodiment of the invention, the collection size is in the range of five 
thousand to ten thousand items. However, the size of the batch submitted may 
vary depending upon the capacity of the system. To perform the query 
collectively, the system inputs the selection criteria in an input table as a single 
INSERT statement. Then, the system performs a single join from the input table 

Q 

yj 10 against the denormalized data table. In the case of blanket appointments, 



m 
FU 



subsequent queries of inherited appointments can be collectively batched as well. 

For example, to validate 100,000 allocations while verifying only licenses, 
the original query would have resulted in 100,000 queries, each requiring a four- 
table join. Not only is this extremely costly in terms of database performance, 

15 but it also results in 100,000 network round trips to communicate with the 
database. In the same example, using the method proposed in the invention, 
there is an initial cost to denormalize the license table. However, this operation 
needs to be performed only once at the beginning of the engine run. Once the 
data is denormalized, the system may use the collective processing technique 

20 described herein. Thus, for each collection of data (e.g., a batch of 5, 000), the 
system requires only two network round-trips: one to insert the criteria into the 
input table, and one to perform a join of the input table against the denormalized 
data table. Considering the batched INSERT as a single statement, to validate the 
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100,000 allocations, the system incurs only the cost of 40 network round-trips, 
and 40 queries, plus the cost of the initial denormalization. 

An embodiment of the invention is configured to interface with a 
Distributor Management System (DMS). An example of such a DMS system can 
be found in the co-pending application (U.S. Serial Number 09/810,514) entitled 
"Method and System for Managing Distributor Information", the specification of 
which is incorporated herein by reference. 

Thus, a method and apparatus for collectively processing credential 
information is described. Particular embodiments described herein are 
illustrative only and should not limit the present invention thereby. The claims 
and their full scope of equivalents define the invention. 
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